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Using the Port Control Protocol (PCP) to Update Dynamic DNS 
Abstract 


This document focuses on the problems encountered when using dynamic 
DNS in address-sharing contexts (e.g., Dual-Stack Lite (DS-Lite) and 
Network Address and Protocol Translation from IPv6 Clients to IPv4 
Servers (NAT64)) during IPv6 transition. Both issues and possible 
solutions are documented in this memo. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This is a contribution to the RFC Series, independently of any other 
RFC stream. The RFC Editor has chosen to publish this document at 
its discretion and makes no statement about its value for 
implementation or deployment. Documents approved for publication by 
the RFC Editor are not a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 


and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7393. 
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1. Introduction 
1.1. Problem Statement 


Dynamic DNS (DDNS) is a widely deployed service to facilitate hosting 
servers (e.g., access to a webcam, HTTP server, FTP server, etc.) at 
customers’ premises. There are a number of providers that offer a 
DDNS service, working in a client and server mode, which mostly use 
web-form-based communication. DDNS clients are generally implemented 
in the user’s router or computer; once changes are detected to its 
assigned IP address, an update message is automatically sent to the 
DDNS server. The communication between the DDNS client and the DDNS 
server is not standardized, varying from one provider to another, 
although a few standard web-based methods of updating have emerged 
over time. 


In address-sharing contexts, well-known port numbers (e.g., port 80) 
won’t be available for every user [RFC6269]. As such, the DDNS 
client will have to register the IP address and/or the external 
port(s) on which the service is listening. Also, the DDNS client has 
to report any change of this IP address and/or the external port(s). 
It will also require the ability to configure corresponding port 
forwarding on Carrier-Grade NAT (CGN) [RFC6888] devices so that 
incoming communications initiated from the Internet can be routed to 
the appropriate server behind the CGN. 


Issues encountered in address sharing are documented in [RFC6269]. 
This document focuses on the problems encountered when using dynamic 
DNS in address-sharing contexts (e.g., DS-Lite [RFC6333] and NAT64 
[RFC6146]). The main challenges are listed below: 


Announce and discover an alternate service port: The DDNS service 
must be able to maintain an alternative port number instead of the 
default port number. 


Allow for incoming connections: Appropriate means to instantiate 
port mappings in the address-sharing device must be supported. 


Detect changes and trigger DDNS updates: The DDNS client must be 
triggered by the change of the external IP address and the port 
number. Concretely, upon change of the external IP address (and/ 
or external port number), the DDNS client must refresh the DNS 
records; otherwise, the server won’t be reachable from outside. 
This issue is exacerbated in the DS-Lite context because no public 
IPv4 address is assigned to the Customer Premises Equipment (CPE). 
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1.2. Scope and Goals 


This document describes some candidate solutions to resolve the 
aforementioned issues with a particular focus on DS-Lite. These 
solutions may also be valid for other address-sharing schemes. 


This document sketches deployment considerations based on the Port 


Control Protocol (PCP) [RFC6887]. Note that DDNS may be considered 
as an implementation of the rendezvous service mentioned in 
[RFC6887]. 


Indeed, after creating an explicit mapping for incoming connections 
using PCP, it is necessary to inform remote hosts about the IP 
address, protocol, and port number for the incoming connection to 
reach the services hosted behind a DS-Lite CGN. This is usually done 
in an application-specific manner. For example, a machine hosting a 
game server might use a rendezvous server specific to that game (or 
specific to that game developer), a SIP phone would use a SIP proxy, 
a client using DNS-Based Service Discovery [RFC6763] would use DNS 
Update [RFC2136] [RFC3007], etc. PCP does not provide this rendezvous 
function. 


The rendezvous function may support IPv4, IPv6, or both. Depending 
on that support and the application’s support of IPv4 or IPv6, the 
PCP client may need an IPv4 mapping, an IPv6 mapping, or both. An 
example illustrating how the DDNS server may implement such a service 
notification functionality if necessary is provided in Section 3. 


This document does not specify any protocol extension but instead 
focuses on the elaboration of the problem space and illustrates how 
existing tools can be reused to solve the problem for some deployment 
contexts. Particularly, this document requires no changes to PCP or 
dynamic updates in the standard domain name system [RFC2136]; rather, 
it is an operational document to make the current DDNS service 
providers aware of the impacts and issues that IPv6 transitioning and 
IPv4 address sharing will bring to them, and it gives solutions to 
address the forthcoming issues. The current DDNS service providers 
usually employ a web-based form to maintain DDNS service registration 
and updates. 


Generic deployment considerations for DS-Lite, including Basic 
Bridging BroadBand (B4) remote management and IPv4 connectivity 
check, can be found in [RFC6908]. This document complements 
[RFC6908] with deployment considerations related to rendezvous 
service maintenance. Additional PCP-related deployment 
considerations are available at [PCP-DEPLOYMENT]. 
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Solutions relying on DNS-Based Service Discovery [RFC6763] or Apple’s 
Back to My Mac (BTMM) Service [RFC6281] are not considered in this 
document. Moreover, this document does not assume that DDNS service 
relies on [RFC2136]. 


IPv4 addresses used in the examples are derived from the IPv4 block 
reserved for documentation in [RFC6890]. DNS name examples follow 
[RFC2606]. 


Solution Space 
1. Locate a Service Port 


As listed below, at least two solutions can be used to associate a 
port number with a service: 


1. Use service URIs (e.g., FTP, SIP, HTTP) that embed an explicit 
port number. Indeed, the Uniform Resource Identifier (URI) 
defined in [RFC3986] allows the port number to be carried in the 
syntax (e.g., mydomain.example:15687). 


2. Use SRV records [RFC2782]. Unfortunately, the majority of 
browsers do not support this record type. 


The DDNS client and DDNS server are to be updated so that an 
alternate port number is signaled and stored by the DDNS server. 
Requesting remote hosts will be then notified with the IP address and 
port number to reach the server. 


-2. Create Explicit Mappings for Incoming Connections 


PCP is used to install the appropriate mapping(s) in the CGN so that 
incoming packets can be delivered to the appropriate server. 


3. Detect Changes 


In a network as described in Figure 1, a DDNS client/PCP client can 
be running on either a CPE or the host that is hosting some services 
itself. There are several possible ways to address the problems 
stated in Section 1.1: 


1. If the DDNS client is enabled, the host periodically issues 
(e.g., 60 minutes) PCP MAP requests (e.g., messages 1 and 2 in 
Figure 1) with short lifetimes (e.g., 30s) for the purpose of 
inquiring an external IP address and setting. If the purpose is 
to detect any change to the external port, the host must issue a 
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PCP mapping to install for the internal server. Upon change of 
the external IP address, the DDNS client updates the records 
accordingly (e.g., message 3 in Figure 1). 


2. If the DDNS client is enabled, it checks the local mapping table 
maintained by the PCP client. This process is repeated 
periodically (e.g., 5 minutes, 30 minutes, 60 minutes). If there 
is no PCP mapping created by the PCP client, it issues a PCP MAP 
request (e.g., messages 1 and 2 in Figure 1) for the purpose of 
inquiring an external IP address and setting up port forwarding 
mappings for incoming connections. Upon change of the external 
IP address, the DDNS client updates the records in the DDNS 
server, e.g., message 3 in Figure 1. 


| 
|3. DDNS updates 
| 
| 


(if any) 
A E + $oS SSeS SSS SSeS + 
|DDNS Client |1. PCP MAP request | CGN/PCP Server | 
|PCP Client/Iwr |------------------- >| (PCP mapping for|80:8080+------ + 
[on CPE or |2. PCP MAP response | port forwarding) |<------ |Client 
[the host itself |<------------------- | | hasaecs + 
3. DDNS updates 

(if any) 
| eee eee >| | 
$--------------- + e + 
IWF = Internetworking Function 


Figure 1: Flow Chart 
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3. Some Deployment Solutions 
3.1. Reference Topology 


Figure 2 illustrates the topology used for the deployment solutions 
elaborated in the following subsections. 


4+-------------- + 4+-------- + 4+--------- + 4+-------- + 4+------- + 
Service DDNS CGN/ PCP Servers 
User tard Server |---- PCP ===) Client j= 

| | | | | Server | | /DDNS | | | 

| | | a | | ciie | | | 

4+-------------- + 4+-------- + 4+--------- + 4+-------- + 4+------- + 

A user DDNS Server AFTR B4 (CPE) A host 
from Internet behind B4 


Figure 2: Implementation Topology 
Figure 2 involves the following entities: 


o Servers: Refers to the servers that are deployed in the DS-Lite 
network, or more generally, an IP address-sharing environment. 
They are usually running on a host that has been assigned with a 
private IPv4 address. Having created a proper mapping via PCP in 
the Address Family Transition Router (AFTR), these services have 
been made available to Internet users. The services may provide 
web, FTP, SIP, and other services though these may not be able to 
be seen as using a well-known port from the outside anymore, in 
the IP address-sharing context. 


o B4(CPE): An endpoint of an IPv4-in-IPv6 tunnel [RFC6333]. A PCP 
client together with a DDNS client are running on it. After a PCP 
client establishes a mapping on the AFTR, an end user may register 
its domain name and its external IPv4 address plus port number to 
its DDNS service provider (DDNS server), manually or automatically 
by a DDNS client. Later, likewise, end users may manually 
announce or let the DDNS client automatically announce IP address 
and/or port changes to the DDNS server. 


o AFTR: Responsible for maintaining mappings between an IPv6 
address, the internal IPv4 address plus internal port, and the 
external IPv4 address plus port [RFC6333]. 


o DDNS server: Maintains a table that associates a registered domain 
name and a registered host’s external IPv4 address/port number 
pair. When being notified of IP address and port number changes 
from a DDNS client, the DDNS server announces the updates to DNS 
servers on behalf of the end user. [RFC2136] and [RFC3007] may be 
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used by DDNS servers to send updates to DNS servers. In many 
current practices, a DDNS service provider usually announces its 
own IP address as the registered domain names of end users. When 
HTTP requests reach the DDNS server, they may employ URL 
Forwarding or HTTP 301 redirection to redirect the request to a 
proper registered end user by looking up the maintained link 
table. 


o Service users: Refers to users who want to access services behind 
an IP address-sharing network. They issue standard DNS requests 
to locate the services, which will lead them to a DDNS server, 
provided that the requested services have been registered to a 
DDNS service provider. The DDNS server will then handle the rest 
in the same way as described before. 


3.2. For Web Service 


Current DDNS server implementations typically assume that the end 
servers host web servers on the default 80 port. In the DS-Lite 
context, they will have to take into account that external ports 
assigned by the AFTR may be any number other than 80, in order to 
maintain proper mapping between domain names and the external IP plus 
port. If a proper mapping is maintained, the HTTP request would be 
redirected to the AFTR, which serves the specific end host that is 
running the servers. 


Figure 3 depicts how messages are handled in order to be delivered to 
the right server. 


Web Visitor DDNS Server AFTR B4 (CPE) Web Server 
behind B4 
| HTTP GET* | | | 
pan e oa >| | | 
ip_DDNS_server | --~----------- > 
HTTP 301 


| HTTP GET* ip_aftr:8001 


| 

| oe | | | 
| | 

| 

| 


| HTTP GET* ip_websrv:8000 


Figure 3: HTTP Service Messages 
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When a web user sends out an HTTP GET message to the DDNS server 
after a standard DNS query, the DDNS server redirects the request to 
a registered web server, in this case, by responding with an HTTP 301 
message. Then, the HTTP GET message will be sent out to the AFTR, 
which will in turn find the proper hosts behind it. For simplicity, 
messages among AFTR, B4, and the web server behind B4 are not shown 
completely; for communications among those nodes, refer to [RFC6333]. 


3.3. For Non-web Service 


For non-web services, as mentioned in Section 2, other means will be 
needed to inform the users about the service information. 


[RFC6763] includes an example of a DNS-based solution that allows an 
application running in the end user’s device to retrieve service- 
related information via DNS SRV/TXT records and list available 
services. In a scenario where such an application is not applicable, 
the following provides another solution for a third party, e.g., a 
DDNS service provider, to disclose services to Internet users. 


A web portal can be used to list available services. A DDNS server 
maintains a web portal for each user’s Fully Qualified Domain Name 


(FQDN), which provides service links to users. Figure 4 assumes 
"websrv.example.com" is a user’s FQDN provided by a DDNS service 
provider. 
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1:92.00 52:,12:2000 


are + hese SSeS + PSSesSssaess + Internet. +-ss--4= T 
|DDNS Client /| |DDNS Server /| |DNS Server | |Visitor| 
| Web Server | | Web Portal | 
to-- 5-777 - + kaa E E + kee E + +------— + 
register | | 
<------------------ > | | 
websrv.example.com | update DNS | 


websrv.example.com 
portal’s IP 


websrv.example.com 
get portal’s IP 


| 
| 
| 
| <---------------- > 
| 


| 

| 

| 

| 

| 
DNS resolve for | 
| 
visit portal of websrv.example.com | 
| 

| 

| 


Figure 4: Update Web Portal 


The DDNS client registers the server’s information to the DDNS 
server, including the public IP address and port obtained via PCP, 
the user’s FQDN, and other necessary information. The DDNS server 
also behaves as a portal server; it registers its IP address, port 
number, and the user’s FQDN to the DNS system so that visitors can 
access the web portal. 


A DDNS server also maintains a web portal for each user's FQDN and 
updates the portal according to registered information from the DDNS 
client. When a visitor accesses "websrv.example.com", a DNS query 
will resolve the portal server’s address and port number, and the 
visitor will see the portal and the available services. 
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Portal: websrv.example.com 


Servicel: web server 


| | 
| | 
| Link: http://192.0.2.1:2000 | 
| | 
| Service2: video | 
| Link: rtsp://192.0.2.1:8080/test.sdp 

|) eiai | 
| | 
+------------------------------------------------------------- + 


Figure 5: An Example of a Web Portal 


As shown in Figure 5, the web portal shows the service URLs that are 
available to be accessed. Multiple services are accessible per a 
user’s FQDN. 


Some applications that are not HTTP based can also be delivered using 
this solution. When a user clicks on a link, the registered 
application in the client OS will be invoked to handle the link. How 
this can be achieved is out of the scope of this document. 


4. Security Considerations 


This document does not introduce a new protocol, nor does it specify 
protocol extensions. Security-related considerations related to PCP 
[RFC6887] and DS-Lite [RFC6333] should be taken into account. 


The protocol between the DDNS client and DDNS server is proprietary 
in most cases; some extensions may be necessary, which is up to the 
DDNS operators. These operators should enforce security-related 
policies in order to keep illegitimate users from altering records 
installed by legitimate users or installing fake records that would 
attract illegitimate traffic. Means to protect the DDNS server 
against Denial of Service (DoS) should be enabled. Note that these 
considerations are not specific to address-sharing contexts but are 
valid for DDNS services in general. 
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